•t 

Attorney Docket No.: 50277-0258 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
BEFORE THE BOARD OF PATENT APPEALS AND INTERFERENCES 



In re Application of 


) Confirmation No.: 7347 


Harlan Sexton, et al. 


) Group Art Unit: 2194 


Application No. 09/5 1 2,62 1 


. ) Examiner: Andy Ho 


Filed: February 25, 2000 





For: SYSTEM AND METHODOLOGY FOR SUPPORTING A PLATFORM 

INDEPENDENT OBJECT FORMAT FOR A RUN-TIME ENVIRONMENT 



Mail Stop Appeal Brief - Patents 

Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 

APPEAL BRIEF 

Sir: 

This Appeal Brief is submitted in support of the Notice of Appeal dated October 26, 

2005. 

L REAL PARTY IN INTEREST 

Oracle International Corporation is the real party in interest. 

IL RELATED APPEALS AND INTERFERENCES 

Appellants are unaware of any related appeals and interferences. 

III. STATUS OF THE CLAIMS 

Claims 1-6, 8-15, and 17-23 are pending in this appeal, in which claims 7 and 16 have 
earlier been canceled. No claim is allowed. This appeal is therefore taken from the final 
rejection of claims 1-6, 8-15, and 17-23 on October 27, 2004. 



OID-1997-048-14 



Attorney Docket No.: 50277-0258 



IV, STATUS OF AMENDMENTS 

No amendment to the claims has been made since the final rejection of the claims on 
October 27, 2004. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The present invention addresses problems associated with managing memory for a 
runtime execution environment. 

A dynamic run-time environment for a language such as JAVA^^^ is responsible for 
managing memory for objects that are created and destroyed during the execution of a 
program. An object is an entity that encapsulates data and, in some languages, operations 
associated with the object. Since the encapsulated data is stored in memory, objects are 
associated with particular regions of memory that are allocated and deallocated by the 
dynamic run-time environment. 

The state of a program, or "program state," is the set of the objects and the 
references between the objects that exist at a specific point in time during the execution of 
the program. A "reference" is used by a run-time environment to identify and ultimately 
access the region of memory for storing the data of the object. Typically, references between 
objects in a run-time environment are encoded using machine pointers. A machine pointer is 
a native object that contains the address of the object in the main memory, which can be a 
real memory address or, more commonly, a virtual address on a machine that implements a 
virtual memory system. Since machine pointers are closely coupled to the underlying 
hardware and firmware of a computer system, machine pointers have high performance and, 
hence, are a popular implementation for references. 

In a run-time environment, however, managing the program state with machine- 
specific references such as machine pointers is sometimes disadvantageous. For example, it 
may be desirable to store the program state on disk or another secondary storage medium and 
restore the stored program state to main memory. Some run-time environments, in fact, are 
designed to use the same program state on different types of machines. For instance, such 
run-time environments provide load-balancing and crash recovery functions by transferring 
the execution of a program from one machine to another. 
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Differences between computer architectures make machine-independence very 
difficuh to achieve. For example, the size of a machine pointer is dictated by the architecture 
of the computer system. While many computer systems today employ 32-bit machine 
pointers, older microprocessors typically used 16-bit machine pointers and the latest 
computer processors are adopting 64-bit pointers. On some 64-bit machines, such as a 
Cray™ supercomputer, all pointers are 64-bits long, and there is no native operation to fetch 
a smaller sized machine pointer. As another example, the significance and ordering of bytes 
in the pointer ("endianness") may vary from processor model to processor model. 

One approach for addressing machine independence, known as "pointer swizzling," 
employs two completely different formats for representing references: a machine-dependent 
runtime format using pointers for references in main memory, and a platform invariant 
format for encoding references in secondary storage. When the reference is written to 
secondary storage, machine pointers are converted into a machine-independent symbol such 
as a string or a serial number. When the reference is read back into main memory from 
secondary storage, the symbol is unswizzled and converted back into a machine pointer: 
Swizzling is also referred to as "serialization" and "pickling." 

The swizzling and the unswizzling operations, however, are computationally 
expensive, requiring many memory accesses into an auxiliary symbol table, typically 
implemented by a hash table or binary tree stored in memory. Thus, frequent storage and 
retrieval of program state into and out of secondary storage can be responsible for a 
significant drain on system performance. In addition, many conventional approaches are 
characterized by substantial manual coding, which is error-prone and renders the source code 
more difficult to maintain. 

Therefore, a need exists for supporting a platform-independent format for object that 
does not require substantial manual coding, that is not error-prone, and that does not render 
the source code more difficult to maintain. (Specification, p. 4:2 - p.5:27) 

A platform-independent format is thus defined for objects as a composition of 
primitive types for use with a platform-specific description of the primitive type. Thus, the 
object can automatically be laid out in a high-level language based on a definition for the 
object in terms of the primitive types and based on a platform-specific description of the 
primitive types. In addition, instructions can automatically be generated for getting and 
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setting values in the object in the platform-independent format, thereby diminishing the 
reliance on manually coding the operations. As a result, errors are reduced and the code is 
more maintainable. (Specification, p. 7:2-9) 

Independent claim 1 (similarly for computer-readable medium claim 10) is directed to 
a method for supporting a platform independent object format for a run-time environment, 
comprising the computer-implemented steps (e.g., FIG. 1, specification, p. 17:21 - p. 18:10) 
of accessing a definition of an object in terms of a composition of one or more primitive 
types (e.g., specification, p. 13:18-24); accessing a platform-specific description of size and 
alignment of the one or more primitive types (e.g., specification, p. 19:5 - p. 20:25, FIG. 3, 
300, 310, 320, 330); and generating a layout for the object in a high-order language based on 
the definition of the object and the size and alignment of the one or more primitive types 
(Specification, p. 20:20 - p. 22:19, FIG. 3, 310, 320, 330, 340). 

Independent claim 8 (similarly for computer-readable medium claim 17) is directed to 
a method for supporting an object format for a plurality of incompatible platforms for a run- 
time environment, comprising the computer-implemented steps (e.g., FIG. 1, specificafion, p. 
17:21 - p. 1.8: 10) of accessing a definition of an object as a plurality of slots containing a 
primitive type (e.g., specification, p. 13:18-24); accessing a plurality of platform-specific 
descriptions of layout parameters of the one or more primitive types, said platform-specific 
descriptions corresponding respectively to the incompatible platforms (e.g., specification, p. 
13:25 - p. 15:13, p. 16:23 - 18:10); and generating a plurality of layouts, corresponding 
respectively to the incompatible platforms, for the object in a high-order language based on 
the definition of the object and the platform-specific descriptions (e.g., specification, p. 16:23 
-p. 22:19). 

Independent claim 21 is directed to a method for supporting an object format for a 
runtime environment, comprising the computer-implemented steps (e.g., FIG. 1, 
specification, p. 17:21 - p. 18: 10) of accessing a definition of an object as including at least 
one slot containing a primitive type (e.g., specificafion, p. 13:18-24); accessing a first layout 
description for the primitive type corresponding to a first platform (e.g., specification, p. 
13:25 - p. 15:13); generating a first layout for the slot of the object in a high-order language 
based on the definition of the object and the first layout description (e.g., specification, p. 
16:23 - p. 22:1.9), and accessing a second layout description for the primitive type 
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corresponding to a second platform (e.g., specification, p. 13:25 - p. 15:13); and generating a 
second layout for the slot of the object in a high-order language based on the definition of the 
object and the first layout description (e.g., specification, p. 16:23 - p. 22:19); wherein the 
first layout for the slot and the second layout for the slot have a same size when compiled by 
a first compiler of the high-order language on the first platform and a second compiler of the 
high-order language on the second platform; and the first layout for the slot of the object in 
the high-order language includes a padding element and the second layout for the slot of the 
object in the high-order language does not include the padding element (e.g., specification, p. 
14:14 -16:21, p. 17:1-26, p. 21:1 - p. 22:19). 

Dependent claim 19 depending from claim 9 which depends from claim 8 
additionally includes wherein one of the platform-specific descriptions corresponding to one 
of the incompatible platforms specifies that the primitive type has a first size; another of the 
platform specific descriptions corresponding to another of the incompatible platforms 
specifies that the primitive type has a second size greater than the first size (e.g., 
Specification, p. 13:25 - 15:2); and said generating the layouts includes generating one of the 
layouts corresponding to said one of the incompatible platforms; generating another of the 
layouts corresponding to said another of the incompatible platforms; and generating a 
padding element in said one of the layouts (e.g., Specification, p. 16:23 - p. 18:10, p. 19:5 - p. 
22:19, FIG. 3). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1-6, 8-15, and 17-23 are obvious under 35 U.S.C. § 103(a) based on 
OVonnell et al (U.S. 6,480,877) and Schofield (U.S. 6,308,225). 

VIL ARGUMENT 

A. CLAIMS 1-6, 8-15, AND 17-23 ARE NOT RENDERED OBVIOUS BY 
O'DONNELL ETAL. AND SCHOFIELD 



The initial burden of establishing a prima facie basis to deny patentability to a 
claimed invention under any statutory provision always rests upon the Examiner. In re 
Mayne, 104 F.3d 1339, 41 USPQ2d 1451 (Fed.Cir. 1997); In re Deuel 51 F.3d 1552, 34 
USPQ2d 1210 (Fed. Cir. 1995); In re Bell, 991 F.2d 781, 26 USPQ2d 1529 (Fed. Cir. 
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1993); In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In rejecting a 

claim under 35 U.S.C. § 103, the Examiner is required to provide a factual basis to support 

the obviousness conclusion. In re Warner, 379 F.2d 1011, 154 USPQ 173 (CCPA 1967); In 

re Lunsford, 357 F.2d 385,148 USPQ 721 (CCPA 1966); In re Freed, 425 F.2d 785, 165, 

USPQ 570 (CCPA 1970). 

Obviousness rejections require some evidence in the prior art of a teaching, 

motivation, or suggestion to combine and modify the prior art references. See, e.g., 

McGinley v. Franklin Sports, Inc., 262 F.3d 1339, 1351-52, 60 USPQ2d 1001, 1008 (Fed. 

Cir. 2001); Brown & Williamson Tobacco Corp, v. Philip Morris Inc, 229 F.3d 1120, 

1124-25, 56 USPQ2d 1456, 1459 (Fed. Cir. 2000); In re Dembiczak, 175 F.3d 994, 999, 50 

USPQ2d 1614, 1617 (Fed. Cir. 1999). 

1. ALL CLAIMS 1-6, 8-15, AND 17-23 ARE NOT RENDERED OBVIOUS 
BY O'DONNELL ETAL. AND SCHOFIELD BECAUSE 
O'DONNELL ETAL, AND SCHOFIELD FAIL TO TEACH OR 
SUGGEST "GENERATING A LAYOUT FOR THE OBJECT" AND 
"ACCESSING A DEFINITION OF AN OBJECT IN TERMS OF ONE 
OR MORE PRIMITIVE TYPES." 

The rejection of claims 1-6, 8-15, and 17-23 should be reversed by the Honorable 
Board because O'Donnell et al and Schofield fail to teach or suggest all the features of the 
claims. 

For example, all the claims recite "computer-implemented steps" or a "computer- 
readable medium bearing instructions" that include "generating a layout" (or a "plurality of 
layouts") "in a high-order language." Although OVonnell et al. shows sample C 
programming language code, O'Donnell et al fails to describe by what means the code is 
generated, much less by "computer-implemented steps" or by execution of instructions on a 
"computer-readable medium" in the manner claimed. 

Indeed, the details in how that code is generated are not the focus of the reference. 
Rather, O'Donnell et al is directed to a way to identify orphan computer processes. As 
explained in col. 2:10-30, "[o]rphan computer processes are computer processes that are 
active or otherwise consume system resources on a computer system but that have no user 
that owns the processes." Processes can become orphans in various ways, e.g. when a 
network connection with a user is lost, but some non-user owned processes are really 
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legitimate system, administration, SQL processes that should not be identified as orphans. 
Accordingly, O'Domell describes the use of an exclude ( ) function that "skips the current 
process if it is in a class or is otherwise identified as a process that is not an orphan" (col. 
7:36-38). The implementation for the exclude {) function is found in the code section of 
cols. 5-6, in which the exclude ( ) function takes a parameter that is a pointer to a structure 
describing the status of a particular process (struct pst_status *proc). As explained in 
col. 9:52-63, the declaration of the pst_status structure is found in a header file supplied 
by a third-party vendor. * Accordingly, since the declaration of the pst_status structure was 
supplied by a third party, it is not surprising that O'Donnell et ai gives no details as to how 
that declaration was generated. 

Moreover, claim 1 specifically recites, "generating a layout for the object in a high- 
order language based on the definition of the object and the size and alignment of the one 
or more primitive types" as a "computer-implemented step." The rejection of claim 1 states 
(Office Action dated July 27, 2005, p. 3): 

generating a layout (struct pst_status *proc, line 32 of code table columns 5- 
6) for the object (proc, line 31 of code table column 5-6) in a high-order 
language (C programming language, lines 9-10 column 6) based on the 
definition of the object (int exclude(proc), line 31 of code table columns 5- 
6) and the size (sizeof(struct pst dynamic), line 26 of code table columns 7- 
8) of the one or more primitive types (int exclude(proc), line 31 of code 
table columns 5-6). 

In the "Response to Arguments" section on pages 4-5 of the Office Action dated 
October 27, 2004, the Examiner contends: 

claim 1 rejection above clearly points out that: "proc" prefer [sic] to the 
"object"; and that "int exclude (proc)" prefers [sic] to "the definition of the 
object", not just the "object" itself. 

Thus, the Examiner equates the recited "object" with the "proc" shovm in the C 
programming language code of columns 5-8 of O'Donnell et al Further, the Examiner 
equates the recited "definition of the object" with the "int exclude (proc) " code of 
O'Donnell et al. In the rejection of claim 1, as best understood, the Examiner apparently 
equates the recited "computer-implemented" step of "generating a layout for the object in a 

' A sample declaration for the pst_status structure apparent from the vendor is found in Appendix A, col. 19-22. 
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high-order language" with the "struct pst_status *proc, line 32 of code table columns 5-6" 
(Office Action dated July 27, 2005, p. 3). However, this code, which is in no way disclosed 
or suggested as having resulted from any "computer-implemented" step of "generating a 
layout," merely shows a declaration of a C language variable, namely "proc," which is 
declared as a pointer to a struct having type "pst_status," which, as discussed above, is 
apparently declared in a header file shown in columns 19-22 of O'Donnell et al. There is 
no disclosure or suggestion of any "layout" of an object "generated" by a "computer- 
implemented" step, by the "struct pst_status *proc" code, in a "high-order language based 
on" the int exclude (proc) code of 0*Donnell et al 

Even if, upon further search or consideration, a reference were to be found showing 
the generation of a layout in a high-order language by "computer-implemented steps" or by 
execution of instructions on a "computer-readable medium," O'Donnell et al still does not 
describe other features of the claims in which the Examiner asserts as being taught. 

For example, claim 1 recites, "generating a layout for the object in a high-order 
language based on the definition of the object and the size and alignment of the one or 
more primitive types." First, the Examiner reads the recited "one or more primitive types" 
on the function declaration int exclude (proc) three times (Office Action dated July 
27, 2005, p. 3), even though a function is not a primitive type in C, the programming 
language used in O'Donnell et al. Second, as the Examiner attempted to assert earlier, the 
function int exclude (proc) does not refer to the definition of an object, much less the 
definition of proc. The function merely returns a 0 or 1 indicating whether process proc 
will be considered for termination. Third, the function int exclude (proc) is 
performing double-duty in the rejection also being equated with "the one or more 
primitive types." A function cannot be both a definition of an object and one or more 
primitive types. Fourth, the sizeof (structure pst_ dynamic) does not give the size of 
int exclude (proc) nor even of the proc parameter, which is a pointer to a struct 
pst_status, not struct pst^dynamic of a different Structure. 

Because Schofield does not cure the defects of O 'Donnell et al (and the Examiner 
does not even assert such), O 'Donnell et al and Schofield, alone or in combination, fail to 
teach or suggest all the features of claim 1 . Schofield is also defective in that Schofield fails 
to suggest what the Examiner asserts. 
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For instance, the Examiner asserted (Office Action dated July 27, 2005, p. 4): 

O'Donnell further does not explicitly teach accessing a platform-specific 
description of alignment of the primitive type. Schofield teaches a system of 
generating a layout of a data structure (lines 48-65 column 3) wherein the 
layout is based on accessing a platform-specific description of alignment of 
the primitive type (...lines 11-18 column 10; ...lines 29-41 column 11). 

Schofield is concerned with providing a way to make transport-independent distributed 
object calls (col. 3:44-45). Specifically, Schofield teaches that a "client application 
generates a request data structure containing the interface data structure and input 
arguments to an operation. The request data structure is packed into a message buffer and 
transported to the server application." (col. 3:61-65). 

It is not clear from the Office Action what the Examiner equates as the "object" of 
claim 1 because of the multiple paragraphs cited, each of which discuss different data 
structures. The Examiner seems to equate the "object" of claim 1 with either the generated 
param structure (col. 9:64 to col. 10:22) of Schofiield or the request data structure (col. 
1 1:29-41; col. 3:61-65) of Schofield. In the case of the former, the param structure, 
generated by the function GLU_INTERFACE_PREPARE, contains the description of one 
parameter belonging to an operation that is being invoked by a client on an object located 
on a server (col. 3:67 to col. 4:2; col, 9:64-65). However, this reading is inconsistent with 
claim 1 which requires that the "object" be "based on the definition of the object and the 
size and alignment of one or more primitive types." The "alignment" described in the 
section cited by the Examiner is an alignment of a parameter of an operation (col. 10:16- 
17; col. 9:64-65). Thus, the parameter of the operation would have to be a primitive type. 
But, as explained above, the parameter of the operation ("param") is a structure, which is 
not a primitive type. Furthermore, claim 1 requires that the "definition of an object" be 
"accessed in terms of a composition of one or more primitive types." Therefore, in order 
for Schofield to read on this feature, the definition of the param structure would have to be 
accessed in terms of the parameter of the operation. Such a reading does not make sense. 

In the case where the latter reading applies (i.e., the "object" of claim 1 is 
equivalent to the request data structure (col. 1 1 :29-41; col. 3:61-65) of Schofield), in order 
to read on claim 1, the definition of the request data structure would have to be accessed 
"in terms of a composition of one or more primitive types." However, the request data 
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structure is composed of a plurality of data structures, including an interface data structure 
and an operation data structure (col. 3:56-63), which are not primitive types. 

Thus, O 'Donnell and Schofield, alone or in combination, fail to disclose or suggest 
all the features of claim 1 . 

2. CLAIMS 8-9 AND 17-20 ARE ALLOWABLE BECAUSE O'DONNELL 
ET AL FAILS TO TEACH OR SUGGEST "INCOMPATIBLE 
PLATFORMS." 

The rejection of claim 8 (Office Action dated July 27, 2005, p. 5) states: 

As to claim 8, it is a method claim of claim 1. Therefore, it is rejected for the 
same reasons as claim 1 above. O'Donnell as modified further teaches 
incompatible platforms (sizeof and struct, line 26 of code table columns 7- 
8). 

Claim 8 clearly recites a "computer-implemented" step of "accessing a plurality of 
platform-specific descriptions of layout parameters of the one or more primitive types, said 
platform-specific descriptions corresponding respectively to the incompatible platforms." 
The rejection of claim 1 states, "accessing a platform-specific description of size 
(sizeof(struct pst_dynamic), line 26 of code table columns 7-8) of the one or more 
primitive types (int exclude (proc), line 31 of code table columns 5-6)." (Office Action 
dated July 27, 2005, p. 3) Appellants respectfully submit that a C language statement 
"sizeof(struct pst_dynamic)" shown as part of code for a printed program listing does not 
disclose or suggest "incompatible platforms" as recited by any of the present claims. The 
statement would be compiled into code that indicates the size, in bytes, of a struct "pst 
dynamic," which does not in any way indicate any information regarding any "primitive 
types" (i.e., a "struct" is not a "primitive type"). Even if the statement were found to 
somehow disclose or suggest "incompatible platforms," the Examiner has given no 
explanation as to how the statement renders claim 1 or 8 obvious. 

3. CLAIMS 9 AND 18 ARE ALSO PATENTABLE BECAUSE 
O'DONNELL ET AL. FAILS TO TEACH OR SUGGEST "LAYOUTS 
FOR THE INCOMPATIBLE PLATFORMS." 

The rejection of claim 9 (Office Action dated July 27, 2005, pp. 5-6) states: 

As to claim 9, O'Donnell as modified further teaches the slots are located in 
the layouts for the incompatible platforms (pw and ps, lines 12 and 28 of 
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code table columns 7-8), when compiled by a corresponding platform- 
specific compiler (compiler, line 8 column 10), at same offsets (line 64 
column 9 to line 12 column 10), 

Again, the Examiner fails to explain how the cited portions of O^Donnell et aL bear 
any relevance to the claimed subject matter of claim 9. There continues to be no disclosure 
or suggestion of any "incompatible platforms," much less any suggestion of "layouts for 
the incompatible platforms" as asserted by the Examiner. The variables pw and ps of 
O'Donnell et aL cited by the Examiner are declared as pointers (struct passwd *pw, struct 
pst_status *ps in cols. 5-8), which, as disclosed in the C program listing of O'Donnell et 
al, do not disclose or suggest "incompatible platforms" or "offsets" as contended by the 
Examiner. 

4. CLAIMS 19-20 ARE ALSO ALLOWABLE BECAUSE O'DONNELL 
ET AL. FAILS TO TEACH OR SUGGEST "ANOTHER OF THE 
PLATFORM-SPECIFIC DESCRIPTIONS... SPECIFIES THAT THE 
PRIMITIVE TYPE HAS A SECOND SIZE GREATER THAN THE 
FIRST SIZE." 

Dependent claim 19, which depends from claim 9, which depends from claim 8, 
recites, "wherein: one of the platform-specific descriptions corresponding to one of the 
incompatible platforms specifies that the primitive type has a first size; another of the 
platform-specific descriptions corresponding to another of the incompatible platforms 
specifies that the primitive type has a second size greater than the first size; and said 
generating the layouts includes: generating one of the layouts corresponding to said one of 
the incompatible platforms; generating another of the layouts corresponding to said another 
of the incompatible platforms; and generating a padding element in said one of the 
layouts." The Examiner contends (Office Action dated July 27, 2005, p. 6): 

As to claim 19, it is a method claim of claim 8. Therefore, it is rejected for 
the same reasons as claim 8 above. O'Donnell as modified further teaches 
primitive types have sizes (parameter size, line 12 column 9) and padding 
element (number of bytes of the structure pst_status, lines 66-67 column 9). 

However, the Examiner completely ignores the specific claim language, e.g., "one 
of the platform-speciflc descriptions corresponding to one of the incompatible 
platforms specifies that the primitive type has a first size" and "another of the platform- 
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specific descriptions corresponding to another of the incompatible platforms specifies 
that the primitive type has a second size greater than the first size." Col. 9:12 of 
0*Donnell et al merely states, "The parameter size of (struct pst_dynamic) returns the size 
of the pst_dynamic structure," which in no way discloses or suggests the claimed features. 
Moreover, the Examiner further ignores the fact that claim 19 depends from claim 9, which 
recites, "where the slots are located in the layouts for the incompatible platforms, when 
compiled by a corresponding platform-specific compiler, at same offsets," which is in no 
way addressed by the rejection of claim 19. 

5. CLAIMS 19-23 ARE PATENTABLE BECAUSE O'DONNELL ET AL. 
FAILS TO TEACH OR SUGGEST THE "PADDING ELEMENT." 



Independent claim 21 recites a "method for supporting an object format for a run-time 
envirorunent, comprising the computer-implemented steps of: accessing a definition of an 
object as including at least one slot containing a primitive type; accessing a first layout 
description for the primitive type corresponding to a first platform; generating a first layout 
for the slot of the object in a high-order language based on the definition of the object and the 
first layout description; and accessing a second layout description for the primitive type 
corresponding to a second platform; and generating a second layout for the slot of the object 
based on the definition of the object and the first layout description; wherein the first layout 
for the slot and the second layout for the slot have a same size when compiled by a first 
compiler of the high-order language on the first platform and a second compiler of the high- 
order language on the second platform; and the first layout for the slot of the object in the 
high-order language includes a padding element and the second layout for the slot of the 
object in the high-order language does not include the padding element." Both claims 19-20 
also recite a "padding element." 

The rejection of claim 21 states, "As to claim 21, it is a computer readable claim of 
claims 8-9 and 19. Therefore, it is rejected for the same reasons as claims 8-9 and 19 above." 
(Office Action dated July 27, 2005, p. 6) The Examiner appears confused because claim 21 is 
clearly a method claim comprising computer-implemented steps, not a computer-readable 
medium. There is no indication of any "including padding element" as contended by the 
Examiner much less a "first layout for the slot of the object in the high-order language 
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includes a padding element" by the "number of bytes of the structure pst_status" shown 
in col. 9:66-67 of O'Donnell et al. 

VIII. CONCLUSION AND PRAYER FOR RELIEF 

For the foregoing reasons, Appellants request the Honorable Board to reverse each 
of the Examiner's rejections. 



Respectfixlly submitted, 



HICKMAN PALERMO TRUONG & BECKER LLP 




Daniel D. Ledesma 

Reg. No. 57,181 

Date: January 2006 
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IX. CLAIMS APPENDIX 

1. (Previously Presented) A method for supporting a platform independent object format for a 
run-time environment, comprising the computer-implemented steps of: 

accessing a definition of an object in terms of a composition of one or more primitive 
types; 

accessing a platform-specific description of size and alignment of the one or more 
primitive types; and 

generating a layout for the object in 'a high-order language based on the definition of 
the object and the size and alignment of the one or more primitive types. 

2. (Original) The method according to claim 1 , further comprising the step of generating 
instructions for an accessor operation to access a slot in the object holding a value for one of 
the one or more primitive types. 

3. (Original) The method according to claim 1, further comprising the step of generating 
instructions for a get operation to fetch a value for one of the one or more primitive types 
from a slot in the object. 

4. (Original) The method according to claim 1, further comprising the step of generating 
instructions for a set operation to store a value for one of the one or more primitive types 
from a slot in the object. 
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5. (Previously Presented) The method according to claim 1, wherein the one or more 
primitive types includes one or more of the following types: integer, floating point, and 
reference. 

6. (Original) The method according to claim 5, wherein the primitive reference type is one 
of a native machine pointer type and a numeric reference type. 

7. (Canceled) 

8. (Original) A method for supporting an object format for a plurality of incompatible 
platforms for a run-time environment, comprising the computer-implemented steps of: 

accessing a definition of an object as a plurality of slots containing a primitive type; 
acciessing a plurality of platform-specific descriptions of layout parameters of the 

one or more primitive types, said platform-specific descriptions 

corresponding respectively to the incompatible platforms; and 
generating a plurality of layouts, corresponding respectively to the incompatible 

platforms, for the object in a high-order language based on the definition of 

the object and the platform-specific descriptions. 

9. (Original) The method according to claim 8, where the slots are located in the layouts for 
the incompatible platforms, when compiled by a corresponding platform-specific compiler, at 
same offsets. 
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10. (Previously Presented) A computer-readable medium bearing instructions for supporting 
a platform independent object format for a run-time environment, said instructions being 
arranged to cause one or more processors upon execution thereby to perform the steps of: 

accessing a definition of an object in terms of a composition of one or more primitive 
types; 

accessing a platform-specific description of size and alignment of the one or more 
primitive types; and 

generating a layout for the object in a high-order language based on the definition of 
the object and the size and alignment of the one or more primitive types. 

11. (Original) The computer-readable medium according to claim 10, wherein said 
instructions are further arranged for performing the step of generating instructions for an 
accessor operation to access a slot in the object holding a value for one of the one or more 
primitive types. 

12. (Original) The computer-readable medium according to claim 10, wherein said 
instructions are further arranged for performing the step of generating instructions for a get 
operation to fetch a value for one of the one or more primitive types from a slot in the object. 

13. (Original) The computer-readable medium according to claim 10, wherein said 
instructions are further arranged for performing the step of generating instructions for a set 
operation to store a value for one of the one or more primitive types fi^om a slot in the object. 
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14. (Previously Presented) The computer-readable medium according to claim 10, wherein 
the one or more primitive types includes one or more of the following types: integer, floating 
point, and reference. 

15. (Original) The computer-readable medium according to claim 14, wherein the primitive 
reference type is one of a native machine pointer type and a numeric reference type. 

16. (Canceled) 

17. (Original) A computer-readable medium bearing instructions for supporting, an object 
format for a plurality of incompatible platforms for a run-time environment, said instructions 
being arranged to cause one or more processors upon execution thereby to perform the steps 
of: 

accessing a definition of an object as a plurality of slots containing a primitive type; 
accessing a plurality of platform-specific descriptions of layout parameters of the one 

or more primitive types, said platform-specific descriptions corresponding 

respectively to the incompatible platforms; and 
generating a plurality of layouts, corresponding respectively to the incompatible 

platforms, for the object in a high-order language based on the definition of 

the object and the platform-specific descriptions. 
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18. (Original) The computer-readable medium according to claim 17, wherein the slots are 
located in the layouts for the incompatible platforms, when compiled by a corresponding 
platform-specific compiler, at same offsets. 

19. (Previously Presented) The method according to claim 9, wherein: 

one of the platform-specific descriptions corresponding to one of the incompatible 
platforms specifies that the primitive type has a first size; 

another of the platform-specific descriptions corresponding to another of the 

incompatible platforms specifies that the primitive type has a second size 
greater than the first size; and said generating the layouts includes: 

generating one of the layouts corresponding to said one of the incompatible 

platforms; generating another of the layouts corresponding to said another of 
the incompatible platforms; and 

generating a padding element in said one of the layouts. 
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20. (Previously Presented) The computer-readable medium according to claim 18, wherein: 
one of the platform-specific descriptions corresponding to one of the incompatible 

platforms specifies that the primitive type has a first size; and 
another of the platform-specific descriptions corresponding to another of the 

incompatible platforms specifies that the primitive type has a second size 
greater than the first size; and said generating the layouts includes: 
generating one of the layouts corresponding to said one of the incompatible 
platforms; 

generating another of the layouts corresponding to said another of the 

incompatible platforms; and 
generating a padding element in said one of the layouts. 
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21. (Previously Presented) A method for supporting an object format for a run-time 
environment, comprising the computer-implemented steps of: 

accessing a definition of an object as including at least one slot containing a primitive 
type; 

accessing a first layout description for the primitive type corresponding to a first 
platform; 

generating a first layout for the slot of the object in a high-order language based on 
the definition of the object and the first layout description; and 

accessing a second layout description for the primitive type corresponding to a second 
platform; and 

generating a second layout for the slot of the object in a high-order language based on 
the definition of the object and the first layout description; 

wherein the first layout for the slot and the second layout for the slot have a same 
size w^hen compiled by a first compiler of the high-order language on the 
first platform and a second compiler of the high-order language on the 
second platform; and 

the first layout for the slot of the object in the high-order language includes a 

padding element and the second layout for the slot of the object in the high- 
order language does not include me padding element. 
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22. (Previously Presented) The method according to claim 21, wherein: 

the first layout description for the primitive type specifies a first size for the primitive 
type; and 

the second layout description for the primitive specifies a second size for the 
primitive type greater than the first size. 

23. (Previously Presented) The method according to claim 21, wherein: 

the first layout description for the primitive type specifies a first alignment restriction 

for the primifive type; and 
the second layout description for the primitive specifies a second alignment 

restriction for the primitive type stricter than the first alignment restriction. 
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